d/changelog: finalise 4.11.1+58-g3b062f5040-1 (fix spaces)

Bleh... sometimes it's too late when you see something wrong, so an
extra commit. :) This is better.

d/changelog: finalise 4.11.1+58-g3b062f5040-1

Update changelog for new upstream 4.11.1+58-g3b062f5040

[git-debrebase changelog: new upstream 4.11.1+58-g3b062f5040]

Update to upstream 4.11.1+58-g3b062f5040

[git-debrebase anchor: new upstream 4.11.1+58-g3b062f5040, merge]

finalise 4.11.1+26-g87f51bf366-3

x86/spec-ctrl: Extend repoline safey calcuations for eIBRS and Atom parts

All currently-released Atom processors are in practice retpoline-safe, because
they don't fall back to a BTB prediction on RSB underflow.

However, an additional meaning of Enhanced IRBS is that the processor may not
be retpoline-safe.  The Gemini Lake platform, based on the Goldmont Plus
microarchitecture is the first Atom processor to support eIBRS.

Until Xen gets full eIBRS support, Gemini Lake will still be safe using
regular IBRS.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 17f74242ccf0ce6e51c03a5860947865c0ef0dc2
master date: 2019-03-18 16:26:40 +0000

x86/msr: Shorten ARCH_CAPABILITIES_* constants

They are unnecesserily verbose, and ARCH_CAPS_* is already the more common
version.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: ba27aaa88548c824a47dcf5609288ee1c05d2946
master date: 2019-03-18 16:26:40 +0000

x86/e820: fix build with gcc9

e820.c: In function ‘clip_to_limit’:
.../xen/include/asm/string.h:10:26: error: ‘__builtin_memmove’ offset [-16, -36] is out of the bounds [0, 20484] of object ‘e820’ with type ‘struct e820map’ [-Werror=array-bounds]
   10 | #define memmove(d, s, n) __builtin_memmove(d, s, n)
      |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~
e820.c:404:13: note: in expansion of macro ‘memmove’
  404 |             memmove(&e820.map[i], &e820.map[i+1],
      |             ^~~~~~~
e820.c:36:16: note: ‘e820’ declared here
   36 | struct e820map e820;
      |                ^~~~

While I can't see where the negative offsets would come from, converting
the loop index to unsigned type helps. Take the opportunity and also
convert several other local variables and copy_e820_map()'s second
parameter to unsigned int (and bool in one case).

Reported-by: Charles Arnold <carnold@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 22e2f8dddf5fbed885b5e4db3ffc9e1101be9ec0
master date: 2019-03-18 11:38:36 +0100

xen: Fix backport of "xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct"

These were missed as a consequence of being rebased over other cmdline
cleanup.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

xen: Fix backport of "x86/tsx: Implement controls for RTM force-abort mode"

The posted version of this patch depends on c/s 3c555295 "x86/vpmu: Improve
documentation and parsing for vpmu=" (Xen 4.12 and later) to prevent
`vpmu=rtm-abort` impliying `vpmu=1`, which is outside of security support.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>

tools/firmware: update OVMF Makefile, when necessary

[ This is two commits from master aka staging-4.12: ]

OVMF has become dependent on OpenSSL, which is included as a
submodule.  Initialise submodules before building.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
(cherry picked from commit b16281870e06f5f526029a4e69634a16dc38e8e4)

tools: only call git when necessary in OVMF Makefile

Users may choose to export a snapshot of OVMF and build it
with xen.git supplied ovmf-makefile. In that case we don't
need to call `git submodule`.

Fixes b16281870e.

Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 68292c94a60eab24514ab4a8e4772af24dead807)

Arm/atomic: correct asm() constraints in build_add_sized()

The memory operand is an in/out one, and the auxiliary register gets
written to early.

Take the opportunity and also drop the redundant cast (the inline
functions' parameters are already of the casted-to type).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
(cherry picked from commit 51ceb1623b9956440f1b9943c67010a90d61f5c5)

x86/pv: Fix construction of 32bit dom0's

dom0_construct_pv() has logic to transition dom0 into a compat domain when
booting an ELF32 image.

One aspect which is missing is the CPUID policy recalculation, meaning that a
32bit dom0 sees a 64bit policy, which differ by the Long Mode feature flag in
particular.  Another missing item is the x87_fip_width initialisation.

Update dom0_construct_pv() to use switch_compat(), rather than retaining the
opencoding.  Position the call to switch_compat() such that the compat32 local
variable can disappear entirely.

The 32bit monitor table is now created by setup_compat_l4(), avoiding the need
to for manual creation later.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 356f437171c5bb90701ac9dd7ba4dbbd05988e38
master date: 2019-03-15 14:59:27 +0000

x86/tsx: Implement controls for RTM force-abort mode

The CPUID bit and MSR are deliberately not exposed to guests, because they
won't exist on newer processors.  As vPMU isn't security supported, the
misbehaviour of PCR3 isn't expected to impact production deployments.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 6be613f29b4205349275d24367bd4c82fb2960dd
master date: 2019-03-12 17:05:21 +0000

x86/vtd: Don't include control register state in the table pointers

iremap_maddr and qinval_maddr point to the base of a block of contiguous RAM,
allocated by the driver, holding the Interrupt Remapping table, and the Queued
Invalidation ring.

Despite their name, they are actually the values of the hardware register,
including control metadata in the lower 12 bits.  While uses of these fields
do appear to correctly shift out the metadata, this is very subtle behaviour
and confusing to follow.

Nothing uses the metadata, so make the fields actually point at the base of
the relevant tables.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
master commit: a9a05aeee10a5a3763a41305a9f38112dd1fcc82
master date: 2019-03-12 13:57:13 +0000

x86/HVM: don't crash guest in hvmemul_find_mmio_cache()

Commit 35a61c05ea ("x86emul: adjust handling of AVX2 gathers") builds
upon the fact that the domain will actually survive running out of MMIO
result buffer space. Drop the domain_crash() invocation. Also delay
incrementing of the usage counter, such that the function can't possibly
use/return an out-of-bounds slot/pointer in case execution subsequently
makes it into the function again without a prior reset of state.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
master commit: a43c1dec246bdee484e6a3de001cc6850a107abe
master date: 2019-03-12 14:39:46 +0100

iommu: leave IOMMU enabled by default during kexec crash transition

It's unsafe to disable IOMMU on a live system which is the case
if we're crashing since remapping hardware doesn't usually know what
to do with ongoing bus transactions and frequently raises NMI/MCE/SMI,
etc. (depends on the firmware configuration) to signal these abnormalities.
This, in turn, doesn't play well with kexec transition process as there is
no handling available at the moment for this kind of events resulting
in failures to enter the kernel.

Modern Linux kernels taught to copy all the necessary DMAR/IR tables
following kexec from the previous kernel (Xen in our case) - so it's
currently normal to keep IOMMU enabled. It might require minor changes to
kdump command line that enables IOMMU drivers (e.g. intel_iommu=on /
intremap=on) but recent kernels don't require any additional changes for
the transition to be transparent.

A fallback option is still left for compatibility with ancient crash
kernels which didn't like to have IOMMU active under their feet on boot.

Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 12c36f577d454996c882ecdc5da8113ca2613646
master date: 2019-03-12 14:38:12 +0100

x86/cpuid: add missing PCLMULQDQ dependency

Since we can't seem to be able to settle our discussion for the wider
adjustment previously posted, let's at least add the missing dependency
for 4.12. I'm not convinced though that attaching it to SSE is correct.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: eeb31ee522c7bb8541eb4c037be2c42bfcf0a3c3
master date: 2019-03-05 18:04:23 +0100

x86/mm: fix #GP(0) in switch_cr3_cr4()

With "pcid=no-xpti" and opposite XPTI settings in two 64-bit PV domains
(achievable with one of "xpti=no-dom0" or "xpti=no-domu"), switching
from a PCID-disabled to a PCID-enabled 64-bit PV domain fails to set
CR4.PCIDE in time, as CR4.PGE would not be set in either (see
pv_fixup_guest_cr4(), in particular as used by write_ptbase()), and
hence the early CR4 write would be skipped.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: fdc2056767ba74346dfd8bbe868bb22521ba1418
master date: 2019-03-05 17:02:36 +0100

x86/nmi: correctly check MSB of P6 performance counter MSR in watchdog

The logic currently tries to work out if a recent overflow (that indicates
that NMI comes from the watchdog) happened by checking MSB of performance
counter MSR that is initially sign extended from a negative value
that we program it to. A possibly incorrect assumption here is that
MSB is always bit 32 while on modern hardware it's usually 47 and
the actual bit-width is reported through CPUID. Checking bit 32 for
overflows is usually fine since we never program it to anything
exceeding 32-bits and NMI is handled shortly after overflow occurs.

A problematic scenario that we saw occurs on systems where SMIs taking
significant time are possible. In that case, NMI handling is deferred to
the point firmware exits SMI which might take enough time for the counter
to go through bit 32 and set it to 1 again. So the logic described above
will misread it and report an unknown NMI erroneously.

Fortunately, we can use the actual MSB, which is usually higher than the
currently hardcoded 32, and treat this case correctly at least on modern
hardware.

Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 0452d02b6e7849537914dd30cbfc8eb27cdad2ce
master date: 2019-02-28 13:44:40 +0000

x86/hvm: Increase the triple fault log message level to XENLOG_ERR

At INFO level, it doesn't get printed out by default in release builds,
leading to unqualified logging such as this:

  (XEN) [   66.995993] Freed 524kB init memory
  (XEN) [ 1993.144997] *** Dumping Dom9 vcpu#2 state: ***
  (XEN) [ 1993.145008] ----[ Xen-4.11.1  x86_64  debug=n   Not tainted ]----
  (XEN) [ 1993.145011] CPU:    21
  (XEN) [ 1993.145015] RIP:    0010:[<ffffe0002ba950ef>]
  (XEN) [ 1993.145018] RFLAGS: 0000000000010246   CONTEXT: hvm guest (d9v2)
  (XEN) [ 1993.145026] rax: 00000000ffffe000   rbx: ffffe0002d8e1440   rcx: 0000ffffe0002ba9
  (XEN) [ 1993.145031] rdx: 0000000000000000   rsi: ffffe0002ba93575   rdi: fffff803dfb9f340
  (XEN) [ 1993.145035] rbp: ffffd001cd791200   rsp: ffffd001cd791140   r8:  0000000000000130
  (XEN) [ 1993.145039] r9:  0000000080000000   r10: 0000000000000000   r11: 0000000000000020
  (XEN) [ 1993.145043] r12: ffffe0002ba9306d   r13: 0000000000000000   r14: 0000000000000001
  (XEN) [ 1993.145047] r15: fffff803dfb9f200   cr0: 0000000080050031   cr4: 0000000000170678
  (XEN) [ 1993.145051] cr3: 00000000001aa002   cr2: 0000020488403f70
  (XEN) [ 1993.145056] fsb: 0000000060f71000   gsb: ffffd001cc1af000   gss: 0000009d60f6f000
  (XEN) [ 1993.145060] ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010

A triple fault is fatal to the domain under all circumstances (so will print
at most once), and in practice is always an error condition rather than a
reboot fallback.

Reported-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 1c8ca185e3c6e003398471edd9dbac0cd118137c
master date: 2019-02-28 11:16:27 +0000

x86/vmx: Properly flush the TLB when an altp2m is modified

Modifications to an altp2m mark the p2m as needing flushing, but this was
never wired up in the return-to-guest path.  As a result, stale TLB entries
can remain after resuming the guest.

In practice, this manifests as a missing EPT_VIOLATION or #VE exception when
the guest subsequently accesses a page which has had its permissions reduced.

vmx_vmenter_helper() now has 11 p2ms to potentially invalidate, but issuing 11
INVEPT instructions isn't clever.  Instead, count how many contexts need
invalidating, and use INVEPT_ALL_CONTEXT if two or more are in need of
flushing.

This doesn't have an XSA because altp2m is not yet a security-supported
feature.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
master commit: 69f7643df68ef8e994221a996e336a47cbb7bbc8
master date: 2019-02-28 11:16:27 +0000

x86/shadow: don't use map_domain_page_global() on paths that may not fail

The assumption (according to one comment) and hope (according to
another) that map_domain_page_global() can't fail are both wrong on
large enough systems. Do away with the guest_vtable field altogether,
and establish / tear down the desired mapping as necessary.

The alternatives, discarded as being undesirable, would have been to
either crash the guest in sh_update_cr3() when the mapping fails, or to
bubble up an error indicator, which upper layers would have a hard time
to deal with (other than again by crashing the guest).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 43282a5e64da26fad544e0100abf35048cf65b46
master date: 2019-02-26 16:56:26 +0100

viridian: fix the HvFlushVirtualAddress/List hypercall implementation

The current code uses hvm_asid_flush_vcpu() but this is insufficient for
a guest running in shadow mode, which results in guest crashes early in
boot if the 'hcall_remote_tlb_flush' is enabled.

This patch, instead of open coding a new flush algorithm, adapts the one
already used by the HVMOP_flush_tlbs Xen hypercall. The implementation is
modified to allow TLB flushing a subset of a domain's vCPUs. A callback
function determines whether or not a vCPU requires flushing. This mechanism
was chosen because, while it is the case that the currently implemented
viridian hypercalls specify a vCPU mask, there are newer variants which
specify a sparse HV_VP_SET and thus use of a callback will avoid needing to
expose details of this outside of the viridian subsystem if and when those
newer variants are implemented.

NOTE: Use of the common flush function requires that the hypercalls are
      restartable and so, with this patch applied, viridian_hypercall()
      can now return HVM_HCALL_preempted. This is safe as no modification
      to struct cpu_user_regs is done before the return.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: ce98ee3050a824994ce4957faa8f53ecb8c7da9d
master date: 2019-02-26 16:55:06 +0100

x86/shadow: don't pass wrong L4 MFN to guest_walk_tables()

64-bit PV guest user mode runs on a different L4 table. Make sure
- the accessed bit gets set in the correct table (and in log-dirty
  mode the correct page gets marked dirty) during guest walks,
- the correct table gets audited by sh_audit_gw(),
- correct info gets logged by print_gw().

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
master commit: db2af23d15077605f286d8ef86c8f5d9c1b8302a
master date: 2019-02-20 17:07:17 +0100

x86/pmtimer: fix hvm_acpi_sleep_button behavior

Commit 19fb14622e941 "x86/pmtimer: move ACPI registers from PMTState to
hvm_domain" misconfigures pm1a_sts for hvm_acpi_sleep_button with
PWRBTN_STS instead of SLPBTN_STS, which leads to
XEN_DOMCTL_SENDTRIGGER_SLEEP causing guest powerdowns. Fix this.

Signed-off-by: Varad Gautam <vrd@amazon.de>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: b22c900c44a2db8db1c53e269e152206e55c273f
master date: 2019-02-20 17:06:25 +0100

x86/pv: _toggle_guest_pt() may not skip TLB flush for shadow mode guests

For shadow mode guests (e.g. PV ones forced into that mode as L1TF
mitigation, or during migration) update_cr3() -> sh_update_cr3() may
result in a change to the (shadow) root page table (compared to the
previous one when running the same vCPU with the same PCID). This can,
first and foremost, be a result of memory pressure on the shadow memory
pool of the domain. Shadow code legitimately relies on the original
(prior to commit 5c81d260c2 ["xen/x86: use PCID feature"]) behavior of
the subsequent CR3 write to flush the TLB of entries still left from
walks with an earlier, different (shadow) root page table.

Restore the flushing behavior, also for the second CR3 write on the exit
path to guest context when XPTI is active. For the moment accept that
this will introduce more flushes than are strictly necessary - no flush
would be needed when the (shadow) root page table doesn't actually
change, but this information isn't readily (i.e. without introducing a
layering violation) available here.

This is XSA-294.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 329b00e4d49f70185561d7cc4b076c77869888a0
master date: 2019-03-05 13:54:42 +0100

x86/pv: Don't have %cr4.fsgsbase active behind a guest kernels back

Currently, a 64bit PV guest can appear to set and clear FSGSBASE in %cr4, but
the bit remains set in hardware.  Therefore, the {RD,WR}{FS,GS}BASE are usable
even when the guest kernel believes that they are disabled.

The FSGSBASE feature isn't currently supported in Linux, and its context
switch path has some optimisations which rely on userspace being unable to use
the WR{FS,GS}BASE instructions.  Xen's current behaviour undermines this
expectation.

In 64bit PV guest context, always load the guest kernels setting of FSGSBASE
into %cr4.  This requires adjusting how Xen uses the {RD,WR}{FS,GS}BASE
instructions.

 * Delete the cpu_has_fsgsbase helper.  It is no longer safe, as users need to
   check %cr4 directly.
 * The raw __rd{fs,gs}base() helpers are only safe to use when %cr4.fsgsbase
   is set.  Comment this property.
 * The {rd,wr}{fs,gs}{base,shadow}() and read_msr() helpers are updated to use
   the current %cr4 value to determine which mechanism to use.
 * toggle_guest_mode() and save_segments() are update to avoid reading
   fs/gsbase if the values in hardware cannot be stale WRT struct vcpu.  A
   consequence of this is that the write_cr() path needs to cache the current
   bases, as subsequent context switches will skip saving the values.
 * write_cr4() is updated to ensure that the shadow %cr4.fsgsbase value is
   observed in a safe way WRT the hardware setting, if an interrupt happens to
   hit in the middle.
 * load_segments() is updated to use the VMLOAD optimisation if FSGSBASE is
   unavailable, even if only gs_shadow needs updating.  As a minor perf
   improvement, check cpu_has_svm first to short circuit a context-dependent
   conditional on Intel hardware.
 * pv_make_cr4() is updated for 64bit PV guests to use the guest kernels
   choice of FSGSBASE.

This is part of XSA-293.

Reported-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: eccc170053e46b4ab1d9e7485c09e210be15bbd7
master date: 2019-03-05 13:54:05 +0100

x86/pv: Rewrite guest %cr4 handling from scratch

The PV cr4 logic is almost impossible to follow, and leaks bits into guest
context which definitely shouldn't be visible (in particular, VMXE).

The biggest problem however, and source of the complexity, is that it derives
new real and guest cr4 values from the current value in hardware - this is
context dependent and an inappropriate source of information.

Rewrite the cr4 logic to be invariant of the current value in hardware.

First of all, modify write_ptbase() to always use mmu_cr4_features for IDLE
and HVM contexts.  mmu_cr4_features *is* the correct value to use, and makes
the ASSERT() obviously redundant.

For PV guests, curr->arch.pv.ctrlreg[4] remains the guests view of cr4, but
all logic gets reworked in terms of this and mmu_cr4_features only.

Two masks are introduced; bits which the guest has control over, and bits
which are forwarded from Xen's settings.  One guest-visible change here is
that Xen's VMXE setting is no longer visible at all.

pv_make_cr4() follows fairly closely from pv_guest_cr4_to_real_cr4(), but
deliberately starts with mmu_cr4_features, and only alters the minimal subset
of bits.

The boot-time {compat_,}pv_cr4_mask variables are removed, as they are a
remnant of the pre-CPUID policy days.  pv_fixup_guest_cr4() gains a related
derivation from the policy.

Another guest visible change here is that a 32bit PV guest can now flip
FSGSBASE in its view of CR4.  While the {RD,WR}{FS,GS}BASE instructions are
unusable outside of a 64bit code segment, the ability to modify FSGSBASE
matches real hardware behaviour, and avoids the need for any 32bit/64bit
differences in the logic.

Overall, this patch shouldn't have a practical change in guest behaviour.
VMXE will disappear from view, and an inquisitive 32bit kernel can now see
FSGSBASE changing, but this new logic is otherwise bug-compatible with before.

This is part of XSA-293.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: b2dd00574a4fc87ca964177f8e752a968c27efb2
master date: 2019-03-05 13:53:32 +0100

x86/mm: properly flush TLB in switch_cr3_cr4()

The CR3 values used for contexts run with PCID enabled uniformly have
CR3.NOFLUSH set, resulting in the CR3 write itself to not cause any
flushing at all. When the second CR4 write is skipped or doesn't do any
flushing, there's nothing so far which would purge TLB entries which may
have accumulated again if the PCID doesn't change; the "just in case"
flush only affects the case where the PCID actually changes. (There may
be particularly many TLB entries re-accumulated in case of a watchdog
NMI kicking in during the critical time window.)

Suppress the no-flush behavior of the CR3 write in this particular case.

Similarly the second CR4 write may not cause any flushing of TLB entries
established again while the original PCID was still in use - it may get
performed because of unrelated bits changing. The flush of the old PCID
needs to happen nevertheless.

At the same time also eliminate a possible race with lazy context
switch: Just like for CR4, CR3 may change at any time while interrupts
are enabled, due to the __sync_local_execstate() invocation from the
flush IPI handler. It is for that reason that the CR3 read, just like
the CR4 one, must happen only after interrupts have been turned off.

This is XSA-292.

Reported-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Sergey Dyasli <sergey.dyasli@citrix.com>
master commit: 6e5f22ba437d78c0a84b9673f7e2cfefdbc62f4b
master date: 2019-03-05 13:52:44 +0100

x86/mm: don't retain page type reference when IOMMU operation fails

The IOMMU update in _get_page_type() happens between recording of the
new reference and validation of the page for its new type (if
necessary). If the IOMMU operation fails, there's no point in actually
carrying out validation. Furthermore, with this resulting in failure
getting indicated to the caller, the recorded type reference also needs
to be dropped again.

Note that in case of failure of alloc_page_type() there's no need to
undo the IOMMU operation: Only special types get handed to the function.
The function, upon failure, clears ->u.inuse.type_info, effectively
converting the page to PGT_none. The IOMMU mapping, however, solely
depends on whether the type is PGT_writable_page.

This is XSA-291.

Reported-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: fad0de986220c46e70be2f83279961aad7394af0
master date: 2019-03-05 13:52:15 +0100

x86/mm: add explicit preemption checks to L3 (un)validation

When recursive page tables are used at the L3 level, unvalidation of a
single L4 table may incur unvalidation of two levels of L3 tables, i.e.
a maximum iteration count of 512^3 for unvalidating an L4 table. The
preemption check in free_l2_table() as well as the one in
_put_page_type() may never be reached, so explicit checking is needed in
free_l3_table().

When recursive page tables are used at the L4 level, the iteration count
at L4 alone is capped at 512^2. As soon as a present L3 entry is hit
which itself needs unvalidation (and hence requiring another nested loop
with 512 iterations), the preemption checks added here kick in, so no
further preemption checking is needed at L4 (until we decide to permit
5-level paging for PV guests).

The validation side additions are done just for symmetry.

This is part of XSA-290.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: bac4567a67d5e8b916801ea5a04cf8b443dfb245
master date: 2019-03-05 13:51:46 +0100

x86/mm: also allow L2 (un)validation to be fully preemptible

Commit c612481d1c ("x86/mm: Plumbing to allow any PTE update to fail
with -ERESTART") added assertions next to the {alloc,free}_l2_table()
invocations to document (and validate in debug builds) that L2
(un)validations are always preemptible.

The assertion in free_page_type() was now observed to trigger when
recursive L2 page tables get cleaned up.

In particular put_page_from_l2e()'s assumption that _put_page_type()
would always succeed is now wrong, resulting in a partially un-validated
page left in a domain, which has no other means of getting cleaned up
later on. If not causing any problems earlier, this would ultimately
trigger the check for ->u.inuse.type_info having a zero count when
freeing the page during cleanup after the domain has died.

As a result it should be considered a mistake to not have extended
preemption fully to L2 when it was added to L3/L4 table handling, which
this change aims to correct.

The validation side additions are done just for symmetry.

This is part of XSA-290.

Reported-by: Manuel Bouyer <bouyer@antioche.eu.org>
Tested-by: Manuel Bouyer <bouyer@antioche.eu.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 176ebf9c8bc2828f6637eb61cc1cf166e302c699
master date: 2019-03-05 13:51:18 +0100

xen: Make coherent PV IOMMU discipline

In order for a PV domain to set up DMA from a passed-through device to
one of its pages, the page must be mapped in the IOMMU.  On the other
hand, before a PV page may be used as a "special" page type (such as a
pagetable or descriptor table), it _must not_ be writable in the IOMMU
(otherwise a malicious guest could DMA arbitrary page tables into the
memory, bypassing Xen's safety checks); and Xen's current rule is to
have such pages not in the IOMMU at all.

At the moment, in order to accomplish this, the code borrows HVM
domain's "physmap" concept: When a page is assigned to a guest,
guess_physmap_add_entry() is called, which for PV guests, will create
a writable IOMMU mapping; and when a page is removed,
guest_physmap_remove_entry() is called, which will remove the mapping.

Additionally, when a page gains the PGT_writable page type, the page
will be added into the IOMMU; and when the page changes away from a
PGT_writable type, the page will be removed from the IOMMU.

Unfortunately, borrowing the "physmap" concept from HVM domains is
problematic.  HVM domains have a lock on their p2m tables, ensuring
synchronization between modifications to the p2m; and all hypercall
parameters must first be translated through the p2m before being used.

Trying to mix this locked-and-gated approach with PV's lock-free
approach leads to several races and inconsistencies:

* A race between a page being assigned and it being put into the
  physmap; for example:
  - P1: call populate_physmap() { A = allocate_domheap_pages() }
  - P2: Guess page A's mfn, and call decrease_reservation(A).  A is owned by the domain,
        and so Xen will clear the PGC_allocated bit and free the page
  - P1: finishes populate_physmap() { guest_physmap_add_entry() }

  Now the domain has a writable IOMMU mapping to a page it no longer owns.

* Pages start out as type PGT_none, but with a writable IOMMU mapping.
  If a guest uses a page as a page table without ever having created a
  writable mapping, the IOMMU mapping will not be removed; the guest
  will have a writable IOMMU mapping to a page it is currently using
  as a page table.

* A newly-allocated page can be DMA'd into with no special actions on
  the part of the guest; However, if a page is promoted to a
  non-writable type, the page must be mapped with a writable type before
  DMA'ing to it again, or the transaction will fail.

To fix this, do away with the "PV physmap" concept entirely, and
replace it with the following IOMMU discipline for PV guests:
 - (type == PGT_writable) <=> in iommu (even if type_count == 0)
 - Upon a final put_page(), check to see if type is PGT_writable; if so,
   iommu_unmap.

In order to achieve that:

- Remove PV IOMMU related code from guest_physmap_*

- Repurpose cleanup_page_cacheattr() into a general
  cleanup_page_mappings() function, which will both fix up Xen
  mappings for pages with special cache attributes, and also check for
  a PGT_writable type and remove pages if appropriate.

- For compatibility with current guests, grab-and-release a
  PGT_writable_page type for PV guests in guest_physmap_add_entry().
  This will cause most "normal" guest pages to start out life with
  PGT_writable_page type (and thus an IOMMU mapping), but no type
  count (so that they can be used as special cases at will).

Also, note that there is one exception to to the "PGT_writable => in
iommu" rule: xenheap pages shared with guests may be given a
PGT_writable type with one type reference.  This reference prevents
the type from changing, which in turn prevents page from gaining an
IOMMU mapping in get_page_type().  It's not clear whether this was
intentional or not, but it's not something to change in a security
update.

This is XSA-288.

Reported-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
master commit: fe21b78ef99a1b505cfb6d3789ede9591609dd70
master date: 2019-03-05 13:48:32 +0100

steal_page: Get rid of bogus struct page states

The original rules for `struct page` required the following invariants
at all times:

- refcount > 0 implies owner != NULL
- PGC_allocated implies refcount > 0

steal_page, in a misguided attempt to protect against unknown races,
violates both of these rules, thus introducing other races:

- Temporarily, the count_info has the refcount go to 0 while
  PGC_allocated is set

- It explicitly returns the page PGC_allocated set, but owner == NULL
  and page not on the page_list.

The second one meant that page_get_owner_and_reference() could return
NULL even after having successfully grabbed a reference on the page,
leading the caller to leak the reference (since "couldn't get ref" and
"got ref but no owner" look the same).

Furthermore, rather than grabbing a page reference to ensure that the
owner doesn't change under its feet, it appears to rely on holding
d->page_alloc lock to prevent this.

Unfortunately, this is ineffective: page->owner remains non-NULL for
some time after the count has been set to 0; meaning that it would be
entirely possible for the page to be freed and re-allocated to a
different domain between the page_get_owner() check and the count_info
check.

Modify steal_page to instead follow the appropriate access discipline,
taking the page through series of states similar to being freed and
then re-allocated with MEMF_no_owner:

- Grab an extra reference to make sure we don't race with anyone else
  freeing the page

- Drop both references and PGC_allocated atomically, so that (if
successful), anyone else trying to grab a reference will fail

- Attempt to reset Xen's mappings

- Reset the rest of the state.

Then, modify the two callers appropriately:

- Leave count_info alone (it's already been cleared)
- Call free_domheap_page() directly if appropriate
- Call assign_pages() rather than open-coding a partial assign

With all callers to assign_pages() now passing in pages with the
type_info field clear, tighten the respective assertion there.

This is XSA-287.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
master commit: 3d4868a481eebed232eeacba36ea28e5dee5e946
master date: 2019-03-05 13:48:08 +0100

IOMMU/x86: fix type ref-counting race upon IOMMU page table construction

When arch_iommu_populate_page_table() gets invoked for an already
running guest, simply looking at page types once isn't enough, as they
may change at any time. Add logic to re-check the type after having
mapped the page, unmapping it again if needed.

This is XSA-285.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tentatively-Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 1f0b0bb7773d537bcf169e021495d0986d9809fc
master date: 2019-03-05 13:47:36 +0100

gnttab: set page refcount for copy-on-grant-transfer

Commit 5cc77f9098 ("32-on-64: Fix domain address-size clamping,
implement"), which introduced this functionality, took care of clearing
the old page's PGC_allocated, but failed to set the bit (and install the
associated reference) on the newly allocated one. Furthermore the "mfn"
local variable was never updated, and hence the wrong MFN was passed to
guest_physmap_add_page() (and back to the destination domain) in this
case, leading to an IOMMU mapping into an unowned page.

Ideally the code would use assign_pages(), but the call to
gnttab_prepare_for_transfer() sits in the middle of the actions
mirroring that function.

This is XSA-284.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
master commit: 6d4f36c3fecc0a6a0991716199612c81d909316e
master date: 2019-03-05 13:45:58 +0100

/etc/default/xen: Handle with ucf

We reintroduced this file in
  "d/xen-utils-common.install: ship /etc/default/xen"
  eg 2f34db35dd27abb4280d38ebc4464c21f64df8c9

But I had forgotten that this file was previously shipped and handled
by ucf; and we have machinery to try to remove it.

This leaves the following possible cases:
(a) stretch: file handled by ucf
(b) older buster: file not shipped, ucf postinst action not done
   | file remains recorded by ucf and ucfr, but that the original
   | version of the file is no longer present on the user's machine
(c) newer buster: file shipped, file recorded by ucf with one
   old version and as dpkg conffile by newer version

(a) and (b) will be handled correctly by just using ucf in the normal
way.

(c) xxx needs testing

So:
 * Drop the special call to ucf-remove-fixup; retain the call to ucf
 * Switch to shipping the file in /usr/share as expected by ucf

We do not remove the file's entry from not-installed - see the
comment relating to #831786.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: start 3~

tools/xl/bash-completion: also complete 'xen'

We have the `xen` alias for xl in Debian, since in the past it was a
command that could execute either xl or xm.

Now, it always does xl, so, complete the same stuff for it as we have
for xl.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
[git-debrebase split: mixed commit: debian part]

d/not-installed: work around dh-exec bug

dh-exec breaks dh_missing by failing to register the installed files.
Put a workaround in place.

Closes: #923013
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

d/[..]/grub.d/xen.cfg: dom0_mem max IS needed

I misread the upstream documentation. Adding max: for x86 is actually
necessary to not have it "attempt to allocate enough page tables to
cover all of *host* RAM which can exhaust its actual memory allocation".

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

changelog: finalise -2

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Packaging change: override lintian warning about fsimage.so rpath.

This warning is spurious.  Normally .debs should not set rpath but in
this case it is needed.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: start -2~

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: finalise for release to sid/buster

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: Remove a trailing space

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: manually edit, preparatory to release

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

changelog: gbp dch --ignore-branch --since=a8ba67214681b6c5a5d7486550585116f1690ed0

On top of bd06240ecc, which was before the gdr new-upstream
The --since is the last edit to d/changelog

(Cherry picked onto my current master, dealing with conflicts.)

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

Update changelog for new upstream 4.11.1+26-g87f51bf366

[git-debrebase changelog: new upstream 4.11.1+26-g87f51bf366]

Update to upstream 4.11.1+26-g87f51bf366

[git-debrebase anchor: new upstream 4.11.1+26-g87f51bf366, merge]

xencommons xenstored startup: Use --pid-file $F not --pid-file=$F

The ocaml libraries in stretch understands only the variant
with separate arguments.  So a build of this package for stretch
produces an error message and C xenstored instead of oxenstored.

Fix this here even in the buster branch since it makes backporting
easier.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

xendomains init script; Add should-dependency on nfs-kernel-server

Perhaps the guests use the hosts's NFS server, as in the case reported
in #826871.

In any case, it seems much more likely that on a system which is an
NFS server and also a Xen host, that the guests depend on the NFS,
rather than vice versa.

The obvious exception would be a driver domain.  Driver domains
probably need to be handled separately anyway, since they must start
before other domains.  (And anyway they are not particularly
well-handled by the current packaging.)

Closes: #826871
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

xendomains init script; Add dependency on $network

xendomains generally needs to start after the bridge is set up.

In
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798510#20
it was reported that for that user this improves things.

We expect that this change may help with (or at least mask) some other
starup races such as that in the original report for #798510.

Closes: #798510
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

hotplug-common: Strip arch-specific libdir from config file

Closes: #862236
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

debian/rules: Fix tiny typo

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

xen init script: don't fail when being run in domU

When installing xen-utils-V in a driver domain domU, it drags in
xen-utils-common, which also contains the init script for xenstored and
xenconsoled.

Installing the package will fail right away, because it exits non-zero
after checking whether it's running in a xen dom0 or not:

 systemd[1]: Starting LSB: Xen daemons...
 xen[7215]: Starting Xen daemons: (warning).
 systemd[1]: xen.service: Control process exited, code=exited, status=255/EXCEPTION
 systemd[1]: xen.service: Failed with result 'exit-code'.
 systemd[1]: Failed to start LSB: Xen daemons.
 dpkg: error processing package xen-utils-common (--configure):
  installed xen-utils-common package post-installation script subprocess returned error exit status 1

Since there's nothing to be fixed, there should not be a warning. It's
totally fine to skip xenstored, xenconsoled and qemu steps in this case,
so just exit cleanly.

Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922033
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

d/[..]/grub.d/xen.cfg: improve docs even more

Ok, I finally tried this, and it's really great that I now have correct
(different) linux kernel options generated for just linux and xen+dom0.

Do more cosmetics and reorganizing to make this wall of comments better
parseable by the eye. It was not obvious to me where sections started
and ended, and I like to have first the explanation and then at the end
the actual variables you can set.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

d/x-u-common.install: install completion as as xl

...and not as xl.sh. All other files in that completions directory also
don't have .sh. This is just cosmetics, but it annoys me. And we have
dh-exec in here now anyway. :]

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

xen init script: move init_dom0 into xenstored start

Executing this is only necessary after starting xenstored. In all other
cases it just prints noop spam to stderr.

    -# /usr/lib/xen-4.11/bin/xen-init-dom0 >/dev/null
    Dom0 is already set up

I don't want to silence stderr, so just move the code into the end of
the xenstored start function.

Also, add a hint that the compatibility if/else part should be removed
after the Buster release.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

xen init script: rewrite xenstored start logic

We're adding oxenstored, and we want use it by default in Xen 4.11.

When doing a Debian upgrade from Stretch to Buster, the xen-utils-common
package will be upgraded to the new version, but it still needs to
support running the Xen 4.8 hypervisor and utils, because the user might
not have rebooted yet, or might boot into the 4.8 hypervisor again
because there were troubles running 4.11.

So, this means that oxenstored might or might not be available, and we
have to deal with that.

See comments in the code for more explanation about the new program
flow.

Also...
* Allow the user to explicitly configure a xenstored binary in
/etc/default/xen.
* Use if statements rather than constructs using || and && to make the
program flow a bit easier to understand.
* Remove the confuscating madness of having 1 as a success return code.
* Don't print the xenstored progress message if we're not touching it.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

d/xen-utils-common.install: ship /etc/default/xen

This file has been in the package before, it contained TOOLSTACK= to
switch between xm and xl. It was abandoned and never cleaned up, so old
installs still have this file.

Ship it again.

Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

oxenstored: Build it

 * Add the relevant build dependencies

     ocaml-native-compilers is good on stretch because it
     will get us better output code.  In buster the
     ocaml-native-compilers package is merged into ocaml-nox.
     In bullseye we can drop ocaml-native-compilers from the list.

 * Drop the rules line that disables the ocaml build.

 * Ship /etc/xen/oxenstored.conf.

 * Placate dh_missing about ocaml development libraries.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
[add trailing comma, fix typo, change bulleseye line]
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>

xen init script: Tidy up wrong/missing Xen version error handling

We no longer want to discard the stderr from xen-dir, and treat this
as a success.  All the reasons why this failure might previously have
been thought tolerable have been dealt with.

Specifically, we will no longer reach this code if we are not running
under Xen, or if we ran this init script on behalf of a xen-utils-V
package for some V different to the running Xen version.

We know we are running under Xen, and that either we're running not as
a result of a maint script, or as a result of a xen-utils-V maint
script for the running Xen version, or as a result of some other maint
script (of which we don't think there are any, but it presumably
expects this code to work).

So if xen-dir fails, let it print its error message, and also exit
nonzero.  And don't mention not running under Xen in our
log_warning_msg.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Hans van Kranenburg <hans@knorrie.org>

xen init script: Do nothing if running for wrong Xen package

See the big comment.  We think that this is responsible for various
bugs and, particularly, reports of mysteriously missing xenconsoled.

For example, this bug would mean that after a Xen version upgrade,
autoremoval of an obsolete xen-utils-V package would stop the running
xenconsoled.  This is obviously awkward to track down, and could occur
many weeks or months after the upgrade.

Closes: #851654
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Hans van Kranenburg <hans@knorrie.org>

xen init script: silently exit status 0 if not running under xen

This script should not complain at all if we are not running under
Xen.  Check this right at the start.

This will enable improvements to the following code, which will no
longer have to deal with the `not running under Xen' case.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Hans van Kranenburg <hans@knorrie.org>

xen version/upgrade handling: Improve an error message

When xen-dir cannot find xen-utils, mention that this might be because
xen-utils-<RUNNING-XEN-VERSION> was already removed.

This is generally helpful, but it does not solve the `missing
xenconsoled' problems because 1. it only changes messages and
2. actually in the init script, the error message is currently
discarded anyway (!)

But, anyway, it is an improvemennt.

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Hans van Kranenburg <hans@knorrie.org>

debian/.gitignore: ignore more debhelper snippets

Stuff like:

debian/xen-utils-common.preinst.debhelper
debian/xen-utils-common.prerm.debhelper

debian/xen-utils-common.*: remove more xend cruft

Ah, these files are still present on my dom0, while they're obsolete and
not shipped any more. Have them removed, so that they don't confuse the
user.

(Someone might run into old documentation about xend and see that the
files are there, and try setting options, which don't do anything
etc...)

Unpacking xen-utils-common (4.11.1-2~) over (4.11.1-2~) ...
Setting up xen-utils-common (4.11.1-2~) ...
Obsolete conffile /etc/default/xend has been modified by you.
Saving as /etc/default/xend.dpkg-bak ...
Removing obsolete conffile /etc/xen/xend-config.sxp ...
Removing obsolete conffile /etc/xen/xend-pci-permissive.sxp ...
Removing obsolete conffile /etc/xen/xend-pci-quirks.sxp ...
[...]

debian/control: bump debhelper builddep to 10

The debian/compat file contains '10', so make sure that there's actually
a debhelper being dragged in that can do everything needed.

This fixes the lintian warning:
    package-needs-versioned-debhelper-build-depends

d/xen-utils-V...: override xen-shim-syms lintian

This is ok, it's not a file that is meant to be executed on the host
system itself.

debian/control: add dh-python build-dep

Lintian is complaining: missing-build-dependency-for-dh_-command

"The source package appears to be using a dh_ command but doesn't build
depend on the package that actually provides it. If it uses it, it must
build depend on it."

debian/libxenstore3.0.symbols: revert ea2334dfe0

This part of commit ea2334dfe0 was left behind after redoing the
packaging and getting all libraries in the right place. The build now
complains about it:

dpkg-gensymbols: warning: some libraries disappeared in the symbols
file: libxentoolcore-4.10.so.1

dpkg-gensymbols: warning: debian/libxenstore3.0/DEBIAN/symbols doesn't
match completely debian/libxenstore3.0.symbols

debian/xen-utils-common.*: remove xend cruft

xend is obsolete and removed. Still, there are some traces of it in init
and other scripts. Remove all of it now.

Also remove a migration step about upgrading to 4.1, since we don't
support directly upgrading from something older than that to the current
package.

d/control: xenstore-utils breaks xen-utils-common

In the theoretical case that xenstore-utils gets upgraded, when
upgrading from Stretch to Buster, and then deliberately gets downgraded
again by the user, a few manual page files could be removed.

In a normal sane upgrade scenario this would never happen.

d/control: have xen-utils-common suggest xen-doc

d/[..]/grub.d/xen.cfg: command line "starter kit"

As pointed out by Gergely in debian bug #919758, the examples in the
grub documentation contain incorrect suggestions, at least for dom0_mem
and earlyprintk.

Correct those, and take the opportunity to refresh all of this a bit,
including the most common set of used options.

Also, point to the online documentation where more explanation about all
options can be found.

(Closes: #919758)

changelog: start an empty changelog for 4.11.1-2~

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

finalise 4.11.1-1

Signed-off-by: Ian Jackson <ian.jackson@citrix.com>

d/changelog: mention further changes done

d/changelog: Add CVE numbers for recent XSAs

d/changelog: lower unreleased version

When building some intermediate packages and installing with dpkg -i, I
still want to be able to 'normally' upgrade with apt to the final
version.

d/changelog: mention XSA fixes

libxl: correctly dispose of dominfo list in libxl_name_to_domid

Tamas reported ssid_label was leaked. Use the designated function to
free dominfo list to fix the leakage.

Reported-by: Tamas K Lengyel <tamas@tklengyel.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: Tamas K Lengyel <tamas@tklengyel.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit f50dd67950ca9d5a517501af10de7c8d88d1a188)

libxl: don't set gnttab limits in soft reset case

In case of soft reset the gnttab limit setting will fail, so omit it.
Setting of max vcpu count is pointless in this case, too, so we can
drop that as well.

Without this patch soft reset will fail with:

libxl: error: libxl_dom.c:363:libxl__build_pre: Couldn't set grant table limits

Reported-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>

correct release note link in SUPPORT.md

The syntax for the release note link in SUPPORT.md is wrong. Correct
that.

Signed-off-by: Juergen Gross <jgross@suse.com>

x86/hvm: Fix bit checking for CR4 and MSR_EFER

Before the cpuid_policy logic came along, %cr4/EFER auditing on migrate-in was
complicated, because at that point no CPUID information had been set for the
guest.  Auditing against the host CPUID was better than nothing, but not
ideal.

Similarly at the time, PVHv1 lacked the "CPUID passed through from hardware"
behaviour with PV guests had, and PVH dom0 had to be special-cased to be able
to boot.

Order of information in the migration stream is still an issue (hence we still
need to keep the restore parameter to cope with a nested virt corner case for
%cr4), but since Xen 4.9, all domains start with a suitable CPUID policy,
which is a more appropriate upper bound than host_cpuid_policy.

Finally, reposition the UMIP logic as it is the only row out of order.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
master commit: 9d8c1d1814b744d0fb41085463db5d8ae025607e
master date: 2019-01-29 11:28:11 +0000

x86/AMD: flush TLB after ucode update

The increased number of messages (spec_ctrl.c:print_details()) within a
certain time window made me notice some slowness of boot time screen
output. Experimentally I've narrowed the time window to be from
immediately after the early ucode update on the BSP to the PAT write in
cpu_init(), which upon further investigation has an effect because of
the full TLB flush that's implied by that write.

For that reason, as a workaround, flush the TLB of the mapping of the
page that holds the blob. Note that flushing just a single page is
sufficient: As per verify_patch_size() patch size can't exceed 4k, and
the way xmalloc() works the blob can't be crossing a page boundary.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Brian Woods <brian.woods@amd.com>
master commit: f19a199281a23725beb73bef61eb8964d8e225ce
master date: 2019-01-28 17:40:39 +0100

xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) construct

When the command line parsing was updated to use const strings and no longer
tokenise with NUL characters, string matches could no longer be made with
strcmp().

Unfortunately, the replacement was buggy.  strncmp(s, "opt", ss - s) matches
"o", "op" and "opt" on the command line, as ss - s may be shorter than the
passed literal.  Furthermore, parse_bool() is affected by this, so substrings
such as "d", "e" and "o" are considered valid, with the latter being ambiguous
between "on" and "off".

Introduce a new strcmp-like function for the task, which looks for exact
string matches, but declares success when the NUL of the literal matches a
comma, colon or semicolon in the command line fragment.

No change to the intended parsing functionality, but fixes cases where a
partial string on the command line will inadvertently trigger options.

A few areas were more than just a trivial change:

 * parse_irq_vector_map_param() gained some style corrections.
 * parse_vpmu_params() was rewritten to use the normal list-of-options form,
   rather than just fixing up parse_vpmu_param() and leaving the parsing being
   hard to follow.
 * Instead of making the trivial fix of adding an explicit length check in
   parse_bool(), use the length to select which token to we search for, which
   is more efficient than the previous linear search over all possible tokens.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
master commit: 2ddf7e3e341df3ccf21613ff7ffd4b7693abe9e9
master date: 2019-01-15 12:58:34 +0000

mm/page_alloc: fix MEMF_no_dma allocations for single NUMA

Currently dma_bitsize is zero by default on single NUMA node machines.
This makes all alloc_domheap_pages() calls with MEMF_no_dma return NULL.

There is only 1 user of MEMF_no_dma: dom0_memflags, which are used
during memory allocation for Dom0. Failing allocation with default
dom0_memflags is especially severe for the PV Dom0 case: it makes
alloc_chunk() to use suboptimal 2MB allocation algorithm with a search
for higher memory addresses.

This can lead to the NMI watchdog timeout during PV Dom0 construction
on some machines, which can be worked around by specifying "dma_bits"
in Xen's cmdline manually.

Fix the issue by ignoring MEMF_no_dma in cases when dma_bitsize is zero,
which means there is no DMA zone. This shouldn't cause any issues for
Dom0 because alloc_heap_pages() will first use higher memory addresses
for satisfying memory allocation requests.

Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 5ac2dddb173b69be259ce4b259e73f971a4816c1
master date: 2019-01-09 15:45:14 +0100

x86emul: work around SandyBridge errata

There are a number of exception condition related errata on SandyBridge
CPUs, some of which are unexpected #UD (others, of no interest here, are
lack of mandated exceptions, or exceptions of unexpected type). Annotate
the one workaround we already have, and add two more.

Due to the exception recovery we have in place for stub invocations
these aren't security issues.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 0d4d9e8f55602415475e04a5dc8b4ad27845a7f9
master date: 2018-12-18 15:19:47 +0100

x86emul: fix 3-operand IMUL

While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
as its title says, it broke the 3-operand form by uniformly using AL/AX/
EAX/RAX as second source operand. Fix this and add tests covering both
cases.

Reported-by: Andrei Lutas <vlutas@bitdefender.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 19232b378fab04997c0612e5c19e82c29b59d99e
master date: 2018-12-18 14:27:09 +0100

x86/hvm: Corrections to RDTSCP intercept handling

For both VT-x and SVM, the RDTSCP intercept will trigger if the pipeline
supports the instruction, but the guest may not have RDTSCP in its featureset.
Bring the vmexit handlers in line with the main emulator behaviour by
optionally handing back #UD.

Next on the AMD side, if RDTSCP actually ends up being intercepted on a debug
build or first-gen SVM hardware which lacks NRIP, we first update regs->rcx,
then call __get_instruction_length() asking for RDTSC.  As the two
instructions are different (and indeed, different lengths!),
__get_instruction_length_from_list() fails and hands back a #GP fault.

This can demonstrated by putting a guest into tsc_mode="always emulate" and
executing an RDTSCP instruction:

  (d1) --- Xen Test Framework ---
  (d1) Environment: HVM 64bit (Long mode 4 levels)
  (d1) Test rdtscp
  (d1) TSC mode 1
  (XEN) emulate.c:147:d1v0 __get_instruction_length: Mismatch between expected and actual instruction:
  (XEN) emulate.c:152:d1v0   insn_index 8, opcode 0xf0031 modrm 0
  (XEN) emulate.c:154:d1v0   rip 0x10475f, nextrip 0x104762, len 3
  (XEN) SVM insn len emulation failed (1): d1v0 64bit @ 0008:0010475f -> 0f 01 f9 0f 31 5b 31 ff 31 c0 e9 c2 db ff ff 00
  (d1) ******************************
  (d1) PANIC: Unhandled exception at 0008:000000000010475f
  (d1) Vec 13 #GP[0000]
  (d1) ******************************

First, teach __get_instruction_length() to cope with RDTSCP, and improve
svm_vmexit_do_rdtsc() to ask for the correct instruction.  Move the regs->rcx
adjustment into this function to ensure it gets done after we are done
potentially raising faults.

Reported-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Brian Woods <brian.woods@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 3fd3fda9c26fc3c4f77250f795ed7ff9d38e2ec6
master date: 2018-12-17 16:28:03 +0000

x86/VT-x: Don't activate VMCS Shadowing outside of nested vmx mode

By default on capable hardware, SECONDARY_EXEC_ENABLE_VMCS_SHADOWING is
activated unilaterally.  The VMCS Link pointer is initialised to ~0, but the
VMREAD/VMWRITE bitmap pointers are not.

This causes the 16bit IVT and Bios Data Area get interpreted as the read/write
permission bitmap for guests which blindly execute VMREAD/VMWRITE
instructions.

This is not a security issue because the VMCS Link pointer being ~0 causes
VMREAD/VMWRITE to complete with VMFailInvalid (rather than modifying a
potential shadow VMCS), and the contents of MFN 0 has already been determined
not to contain any interesting data because of L1TF's ability to read that 4k
frame.

Leave VMCS Shadowing disabled by default, and toggle it in
nvmx_{set,clear}_vmcs_pointer().  This isn't the most efficient course of
action, but it is the most simple way of leaving nested-virt working as it did
before.

While editing construct_vmcs(), collect all default secondary_exec_control
modifications together.  The disabling of PML is latently buggy because it
happens after secondary_exec_control are written into the VMCS, although there
is an unconditional update later which writes the correct value into hardware.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 75ce36eb72cb93e8a3c9f60fd5e697067921d712
master date: 2018-12-10 16:24:08 +0000

x86/shadow: don't enable shadow mode with too small a shadow allocation

We've had more than one report of host crashes after failed migration,
and in at least one case we've had a hint towards a too far shrunk
shadow allocation pool. Instead of just checking the pool for being
empty, check whether the pool is smaller than what
shadow_set_allocation() would minimally bump it to if it was invoked in
the first place.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
master commit: 2634b997afabfdc5a972e07e536dfbc6febb4385
master date: 2018-11-30 12:10:39 +0100

ns16550/PCI: fix skipping of devices

Selecting between single/multiple BAR mode should happen after checking
whether to skip the present device, or else multi-BAR devices won't be
skipped correctly, due to port_idx getting set to zero in that case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
master commit: c34fe0468acc61aca62422483c37a1309708f1cb
master date: 2018-11-30 12:07:33 +0100

x86/soft-reset: Drop gfn reference after calling get_gfn_query()

get_gfn_query() internally takes the p2m lock, and this error path leaves it
locked.

This wasn't included in XSA-277 because the error path can only be triggered
by a carefully timed phymap operation concurrent with the domain being paused
and the toolstack issuing DOMCTL_soft_reset.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: e7969e917cef276318f722a607985a2e896aeb94
master date: 2018-11-22 17:58:46 +0000

x86/mem-sharing: Don't leave the altp2m lock held when nominating a page

get_gfn_type_access() internally takes the p2m lock, and nothing ever unlocks
it.  Switch to using the unlocked accessor instead.

This wasn't included in XSA-277 because neither mem-sharing nor altp2m are
supported.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: d6e02850d3b45c9658457214a749cc48097bdef4
master date: 2018-11-22 17:58:46 +0000

x86/HVM: __hvm_copy() should not write to p2m_ioreq_server pages

Commit 3bdec530a5 ("x86/HVM: split page straddling emulated accesses in
more cases") introduced a hvm_copy_to_guest_linear() attempt before
falling back to hvmemul_linear_mmio_write(). This is wrong for the
p2m_ioreq_server special case. That change widened a pre-existing issue
though: Other writes to such pages also need to be failed (or forced
through emulation), in particular hypercall buffer writes.

Reported-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: d7bff2bc003cd5fd8c618b70c62b8fcfd9cd187e
master date: 2018-11-15 16:42:25 +0100

update Xen version to 4.11.2-pre